[세션 레포트]Amazon S3를 개발 및 운용하는 방법 – 거대한 마이크로 서비스와 조직 #AWSSummit

안녕하세요! 클래스메소드의 임홍기입니다.
2020.09.08(화) AWS Summit Online Korea에 이어서 AWS Summit Online Japan이 개최되었습니다.

본 포스트 이외에도 서밋 온라인 재팬의 다양한 세션의 리포트가 작성되어 있으니 관심 있으시면 읽어보세요!

본 포스트에서는 2번 트랙의 [Amazon S3를 개발 및 운용하는 방법 (거대한 마이크로서비스와 조직)] 세션을 포스팅하고 있습니다. 포스트에 사용된 해당 세션은 Japan Summit 2020 AWS-33(일본어)을 참고해주세요!

세션 정보

발표자

Amazon S3 Systems Development Engineer 료스케 이와나가 님

개요

아마존 S3는 10년 이상 가동되어 많은 고객에게 이용되고 있습니다. S3의 출발점이자 가장 중요한 기능인 고가용성, 내구성을 유지하며 혁신적인 새로운 기능을 추가하기 위해 저희는 거대한 마이크로 서비스 시스템을 지속적으로 설계하고 운용하며 진화해 나가고 있습니다. 본 세션에서는 실제 이야기와 Amazon Builders' Library를 사용하여 우리 시스템 아키텍처의 특징과 거대한 조직을 운영하기 위한 흥미로운 방법론을 소개합니다. 여러분에게는 큰 멀티 테넌트의 마이크로 서비스 시스템을 효율적으로 만들고 움직이기 위한 시스템 디자인 패턴, 조직의 전략, 그리고 개발자 겸 운용자의 체험 등을 전해드릴 수 있다고 생각합니다.

목표

• Amazon S3의 대규모 개발에 대한 지식
  • 어떤 태세로 조직 및 시스템을 구성 해야 하는가, 누가 운용하는가
  • 소수 인원으로 거대한・복수의 서비스를 어떻게 개발 및 운용하는가
  • 장애에 대한 내구성이 있는 서비스를 어떻게 설계하는가
• 다루지 않는 내용 : S3 서비스의 소개

S3를 구성하는 마이크로 서비스

• 10년 만에, 8개에서 235개 이상의 마이크로 서비스로 성장
  • 참고: Building for Durability in Amazon S3 and Glacier
• 어째서 마이크로 서비스인가?
  • 각 서비스의 책임 범위를 명확하게 해서, 적절한 Ownership을 가지게 하기 위해
  • 2-pizza rule의 인원으로 개발 운용이 되는 범위
  • 팀의 최적 사이즈 = 2개의 피자를 먹을 수 있는 사람 수(최대 10명)
• 마이크로 서비스의 Ownership
  • 서브 시스템 : 대부분의 독립된 조직, 서브 시스템 간은 소결합
  • 서비스 : 하나의 일을 수행하는 애플리케이션
  • 팀 : 서비스 = 1 : N
  • Oncall 로테이션의 대부분은 팀 레벨로 세분화
  • 서비스 소유권도 자주 바뀜
  • 예) 서비스 C의 규모가 커지면서, 2개의 서비스 관리가 힘들어짐으로 새로운 팀3를 만들어 소유권을 이동한다.

모니터링

모니터링을 하는 이유

• 모니터링의 요소
  • 계측 = 필요충분한 수치를 수시로 취득하는 것
  • 감시 = 계측한 값을 계속 검사해 이벤트를 통지하는 것
  • CloudWatch : 계측 = 메트릭, 감시 = 알람
• 모니터링이 중요한 이유
  • 온갖 판단의 재료가 되기 때문
  • 예) 지금 서비스는 안전한가, 반년 후 용량은 충분한가, 다음 분기는 어떤 것을 개선하면 효과가 높은가 등의 판단 재료가 된다.
  • 이 판단을 전형화 할 수 있으며, 자동화 할 수 있기 때문
  • 예) 가용성 저하 -> Oncall통지, 높은 레이턴시, 대기열이 쌓여있음 -> 자동 처리 등
  • 팀의 리소스(가용성 저하의 메트릭 리뷰) 등의 고도한 태스크에 활용할 수 있으며, 서비스를 더욱 빠르게 개선할 수 있다.

무엇을 계측하는가?

• 리퀘스트 로그 : 애플리케이션이 관측한 것을 가능한 한 전부
  • 예) 1 API 리퀘스트 처리
  • 전체 걸린 시간, 이외의 API를 호출할 때 회수, 시간, 계산한 코드 수, 캐시 시간 등

• 작업 단위로 하나의 엔트리를 구조화하여 출력, 활용
  • 단위 : 1API 처리(API 서버), 1 워크플로처리 등(워크 시스템)
• 메트릭으로써 활용할 때, 애플리케이션 내부에서 타이머, 카운터 등을 활용해서 메트릭을 생성할 수 있다.
  • 예) API 리퀘스트에서 걸린 시간 등을 활용해 메트릭을 구성하거나, 성공 실패 여부로 가용성 계측을 할 수 있다.
• 애플리케이션 로그 : 구조화되지 않은 정보/메트릭 이외의 정보
  • Apache Log4j 등의 로그 - 사람에게 유용한 정보
  • 리퀘스트 ID 등을 포함하는 것으로, 디버그 시 검색하기 쉽고 유효하게 활용 할 수 있는 것이 중요
• 기초적인 수치 : 인스턴스 수, CPU/메모리/네트워크/디스크 등

계측한 데이터를 감시

• 각종 메트릭에 대해 적절한 알람을 설정
  • 어떤 통계정보를 이용할 것인가, 그 기간은?
  • 백분위나, 최대 최소, 시간을(1분마다 or 5분마다) 고려해서 사용할 필요가 있다.
  • 평균 수치의 설정, 동작 조건, 종료 조건 등을 적절히 사용해야 한다.
• 알람을 적절한 정도로 통합해나가기
  • 하나의 서비스에도 감시하고 싶은 것이 복수 있다면
  • 예) 가용성, 레이턴시, 캐시용량 등
  • 복수의 감시 목록을 통합하는 것으로, 서비스 전체의 상태를 나타낼 수 있다.
• 알람을 자동화에 이용하기
  • 예) 서비스가 안전하지 않으면, 배포하지 않는다 등

Design for Failure

• 거대한 서비스는 다양한 레이어에서 장애가 발생한다. (발생했을 때 영향 범위가 중요)
  • 예) 인스턴스 장애, 네트워크 장애, 잘못된 배포(사람에 의한 장애) 등
• Poison pill : 단 하나의 장애로 서비스가 멈춰버리는 것
  • 예) 무한 루프가 되어버리는 리퀘스트, 성공할 수 없는 기능 등 따라서 예측할 수 있는 장애에 대해 내구성을 가지는 것이 중요

Blast Radius(폭발 반경)를 가능한 한 작게 만드는 것이 중요 - 물리적인 장애에 대해 다중화하는 것이 기본 - 인스턴스 장애 -> 다중 인스턴스로 극복 - 가용영역 장애 -> 복수의 가용영역 구성 등

Cell Architecture

• 복수 가용영역(Multi-AZ) 구성을 소프트웨어 레벨로 처리 = 복수 Cell
  • 예) 하나의 리전중, N개의 같은 시스템을 구축하여, 데이터를 분할하여 보존
  • Blast Radius = 1/N (Cell 안에 복수 AZ를 구성)
  • 모든 Cell의 앞단에 얇은 라우팅 레이어를 구성하는 것으로, 유저 입장에서는 투과적으로 보이게 됨
  • 예) 어카운트 ID에 Cell을 맵핑, 리소스 ID에 Cell을 맵핑 등

다중 가용영역 구성을 하는 것으로 하나의 가용영역에 장애가 발생해도 전 서비스 장애가 발생하지 않도록 할 수 있다.

이렇게 하는 것으로 Blast Radius = 1/N가 된다.
Cell 1에 장애가 발생해도 Cell 2의 유저는 영향을 끼치지 않게 구성할 수 있다.

셔플 샤딩

셔플 샤딩이란?
셔플 샤딩은 특히 Poison pill의 케이스에서 유효하다.

• Poison pill의 영향 범위
  • case) 특정 유저가 의도하지 않은 버그를 발생시키는 리퀘스트를 계속해서 하는 경우
  • 아래 그림과 같이 전 인스턴스가 균등하게 처리를 하는 경우 (앞단에 로드벨런서가 작동 등의 패턴)
  • Poison pill의 리퀘스트가 모든 인스턴스에 도달하기 때문에 시스템이 일제히 다운되어버린다.

• 이걸 나누기 위한 기술로서, 유저나 리소스 단위로 클러스터를 분담한다. (샤딩)
  • 아래 그림과 같이 특정 클러스터가 다운되기 때문에 서비스 전체가 다운되는 것을 방지할 수 있다. (위에 설명한 Cell도 비슷한 원리)
  • 하지만 특정 클러스터(파란색)는 다운되어 버리기 때문에 영향을 받게 된다. (Noisy neighbor problem이라고도 불림)

• 이 문제를 해결하기 위해, 셔플 샤딩이라는 기술이 등장
  • 샤딩은 하지만, 분할은 유동적으로 하는 기술을 사용
  • 아래 그림과 같이, 특정 유저에게 장애가 발생해도, 겹치지 않는 범위에서는 장애를 줄일 수 있다.
  • 대부분의 유저가 Noisy neighbor과 같은 클러스터를 이용하지 않음으로 리퀘스트 성공률이 0가 아니게 된다.

참고 : re:Invent 2018 session - How AWS Minimizes the Blast Radius of Failures(ARC338)

자동으로 시스템을 복원하기 위해서는?

• 장애에 따라서는 자동으로 해결할 수 있는 것도 있다.
  • 예) 단일 인스턴스 장애(끊는 것으로 해결), 분산처리 데이터의 파손(새로운 데이터를 카피), 핫 파티션(파티션 분리) 등
• 시스템의 역할

• 데이터 플레인 : 유저의 리퀘스트를 처리한다. (API서버 등)
  • 대규모로 분산하고 있으므로, 자율적으로 협조하여 수리하는 것은 어렵다.
  • 예) 모든 인스턴스가, 스스로 문제가 있다고 판단해버리면? -> 모두 동시에 재부팅되면서 서비스가 정지될 수 있다.
• 컨트롤 플레인 : 시스템의 두뇌 (이러한 문제를 피하고자, S3 같은 거대시스템은 컨트롤 플레인을 마련)
  • anomaly : 지점별로 보고받는 장애, 신호 정보 (인스턴스 장애, 핫 파티션 등)
  • workflow : 장애를 복원하기 위한 순서 (데이터 이동, 분리, 변환 등)
  • scheduler : anomaly를 총합하여, 필요한 workflow를 개시하는 역할

아키텍처로 컨트롤 플레인 이해하기

자주 있는 아키텍처로서, 로드벨런서가 있고 EC2 인스턴스가 뒤에 있는 API 시스템을 예를 들면

• 데이터 플레인 : EC2 Instance + Elastic Load Balancing
• 컨트롤 플레인 : EC2 Auto Scaling
• 자동 복원의 예
  • anomaly : CPU 부하의 증감, 인스턴스 장애, 스케줄 실행, AZ 간 밸런스, 예측 등
  • workflow : EC2의 추가 및 삭제
  • scheduler : AutoScaling이 anomaly를 시작으로 workflow를 실행 -> 결과적으로 anomaly가 해소 (ex. CPU 부하가 줄어듦)

컨트롤 플레인의 예) S3의 경우

• 분산처리한 데이터 스토어 서버 1대에 장애 발생
  • anomaly : 특정 서버에 장애가 발생
  • workflow : 해당 서버 위에 있어야 할 데이터를, 다른 안전한 서버에 재배치
  • scheduler : 장애가 있는 서버가 복수일 경우, 일제히 복원해도 좋은지, 순서대로 복원해야 하는지 판단
• 핫 파티션
  • anomaly : 특정 데이터에 액세스가 많아짐
  • workflow : 액세스가 많은 데이터를 분할하여, 다른 파티션으로 이동
  • scheduler : anomaly를 보고 이외에 해당 데이터 위에서 workflow가 실행되고 있지 않은지 확인한 뒤 파티션을 분할

자동화된 파이프라인

• 각 마이크로 서비스마다 자동화된 파이프라인을 가지고 있음
  • 이 파이프라인은 코드의 변경으로부터 프로덕션 환경의 배포를 (반)자동으로 실행
  • 스테이징 환경까지는 완전 자동으로, 프로덕션 환경의 배포는 반자동(사람)으로 실행
  • 이렇게 하는 것으로 정상적인 배포 작업의 작업이 줄어서 시간 절약이 가능
• 가장 중요한 것은 제대로 감시가 되고 있다는 것이 중요
  • 배포 전 : 의존 서비스를 포함하여 안전하지 않은 경우 배포 중단
  • 배포 중 : 서비스 안전성이 보장되지 않으면, 중지한 뒤 롤백
  • 배포 후 : 서비스 안정성이나 그 이외 필요한 메트릭에 이상이 있으면, 롤백

카나리아

테스트 기법의 하나로서 운영 환경에 '카나리아 환경'을 하나 만들어 놓고 트래픽의 일부를 카나리아 환경으로 보내서 운영 환경에서 테스트 했을 때 리스크를 줄이는 방법 -> 배포 관련 Blast Radius를 작게 하는 기술이다.

보통 카나리아 하면 하나의 개념으로 알고 있지만, AWS의 카나리아는 크게 2가지가 있다.

OneBox = 동일 서비스 중 한대의 환경 - 먼저 배포한 뒤, 안전하지 않다면 자동으로 롤백 - 문제가 발생해도 하나의 환경밖에 영향을 끼치지 않으니 Blast Radius를 작게 만들 수 있다. - OneBox만의 메트릭을 기록할 수 있기 때문에, 안정성을 측정할 수 있다.

카나리아 = 정상적으로 계속해서 리퀘스트를 보낼 수 있는 시스템 - 유저 트래픽에 상관 없이 일정 감시가 가능하다. - 카나리아를 이용하는 것으로, 배포의 전 중 후에 카나리아에 이상이 있으면 롤백할 수 있다. - 배포 이외에도 롤백이 되고 있진 않은지 확인 - 다수의 유저가 영향을 받기 전에, 감지하여 대응할 수 있다.

실제 파이프라인 이미지

• 운영 환경으로 배포 전, 테스트 환경에 자동 배포
• Blockers
  • 의존 서비스를 포함한 안전성 검사
• Approval Workflows
  • 서비스의 안전성을 일정 시간 검사
  • 카나리아의 안정성 등
  • 중요한 메트릭이 일정량 관측되고 있는가
  • 예) GET 요청이 5분간 5,000번 이상 성공되었는가
• Wave
  • 순차적으로 배포 Wave1, 2, 3
  • 한 번에 모든 리전에 배포하지 않는다 = Blast Radius를 작게 관리

정리

• Amazon S3의 대규모 개발에 대한 지식
  • 어떤 태세로 조직 및 시스템을 구성 해야 하는가, 누가 운용하는가
  • 2-pizza rule + 마이크로 서비스에서 Ownership을 명확히, 개발자가 운용의 책임을 갖는다
  • 소수 인원으로 거대한・복수의 서비스를 어떻게 개발 및 운용하는가
  • 철저한 모니터링과 자동화 (안전하고, 간단하게)
  • 장애에 대한 내구성이 있는 서비스를 어떻게 설계하는가
  • Blast Radius를 작게 관리하고, 컨트롤 플레인으로 자동 복원하는 설계를 갖춘다
• 다루지 않는 내용 : S3 서비스의 소개

참고 : The Amazon Builder's Library

• 모니터링
  • 운영 가시성을 위한 분산 시스템 계측
• 지속적인 전달
  • 지속적 전달을 통한 신속한 배포
  • 안전한 자동 배포 자동화
• 가용성
  • 셔플 샤딩을 사용한 워크로드 격리
  • 가용 영역을 사용한 정적 안정성